home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19990725-20000114 / 000366_news@columbia.edu _Fri Dec 17 19:05:43 1999.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA15839
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 17 Dec 1999 19:05:43 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA02697
  7.     for kermit.misc@watsun.cc.columbia.edu; Fri, 17 Dec 1999 18:37:01 -0500 (EST)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Subject: Re: Timeout / retry on send
  11. Message-ID: <qxHGNBSm21fQ@cc.usu.edu>
  12. Date: 17 Dec 99 14:29:22 MDT
  13. Organization: Utah State University
  14. To: kermit.misc@columbia.edu
  15.  
  16. In article <s5l4gmh1qrs137@corp.supernews.com>, "Steve Baus" <steve@baus-systems.com> writes:
  17. > I am using DOS ver 3.15 to automate a send and receive over a modem.
  18. > Computer A is in server mode waiting for computer B to send a file.  Once it
  19. > gets the file, computer A does some processing, creates a file, which may be
  20. > a couple of hundred K in size, and tries to send that file.  If there is a
  21. > problem with this send, I would like computer A to abort within a maximum
  22. > time or retries.
  23. > 
  24. > My thought is since the file transfer may take multiple minutes, I should
  25. > have it abort on too many retries like 20.  If I could set the time between
  26. > retries to be say 2 seconds then in theory if I get a dropped connection it
  27. > should abort in 40 seconds.  Looking through my Using MS-DOS Kermit book and
  28. > C-Kermit I would think in my script I would simply have to set retries 20
  29. > and set send timeout 2 and that should do it.  When I test this concept,
  30. > every retry seems to take longer and longer, the first few zip right along
  31. > then it takes a couple of seconds between and each one is longer than the
  32. > last and when I set retries to 20, it abouts on retry 61, when I set retry
  33. > to 8 it aborts on 25.
  34. > 
  35. > Any thoughts?
  36. > Steve
  37. ----------
  38.     Retry intervals are purposefully made exponentially longer because
  39. the range of comms channel characteristics is very wide indeed. Usually
  40. accepting only two or maybe three retries is fairly safe because one packet
  41. may be dropped but not likely two or three. That will shorten the window
  42. of detecting no-client. Also your modem will have hung up the connection
  43. if the client side does so first.
  44.     Joe D.